gtafandomcom-20200222-history
Collision File
All 3D Universe games (Grand Theft Auto III, Grand Theft Auto: Vice City, Grand Theft Auto: San Andreas) have separate files for the visual and physical representations of their models. Collision models are often simply an optimized equivalent of the visual model, reduced in poly count and complexity. The game engine uses them for collision and physics calculations. Unlike graphics meshes, they are comprised not only of triangles but also spheres and boxes, for which exist faster and more accurate collision algorithms. One or more collision models are packaged to a collision file, denoted by the file extension ".col". Each collision model is identified by a name, which must be the same as the model file and the item definition. Version Differences The col format was first introduced with Grand Theft Auto III, referred to as version 1 here. The game's successor, Grand Theft Auto: Vice City used exactly the same format. In the PlayStation 2 version of Grand Theft Auto: San Andreas, however, a new version was used (version 2), which was later updated for the PC and Xbox releases (version 3). Feature Matrix The following matrix is supposed to give an in-depth feature overview of the 3 known versions of the 3D Universe collision file format. Explanation The main difference between the old version 1 format and the new version 2 and 3 formats is the reduced file size. Faces and vertices are only half as big, shrinking models without spheres and boxes to almost 50%. Also, face groups have been introduced, which should speed up collision tests for large models, provided they are calculated properly. Another new feature are the light intensity values, which are a simple but effective way to achieve realtime lighting. You can define a 1 byte lighting value per face, which causes characters and vehicles to change their brightness when they step onto the face. This is used to simulate darkness in places where the sun cannot reach, such as under buildings, etc. And finally version 3 introduces a shadow mesh, which is used to create projected shadows. They only include the faces you want to cast a shadow (like bridges); spheres and boxes are not possible. You can mix all formats within one collision file as you wish, just make sure the target game does support all of them (see matrix above). File Format As mentioned above, the collision files are containers for one or more collision models. They do not have a header; models are stored linearly without any padding. So basically, collision files are simply arrays of collision models. Structures The following data types and structures are used within this article: * INT8/UINT8 - signed/unsigned 8 bit integer (1 byte) * INT16/UINT16 - signed/unsigned 16 bit integer (2 byte) * INT32/UINT32 - signed/unsigned 32 bit integer (4 byte) * FLOAT - single precision floating point number (4 byte) * TVector - float3 (12 byte) Some complex structures vary between the format versions. Structure Name Version 1 Version 2/3 ;TBounds : bounding objects (box & sphere) (40 byte) radius : float; center : TVector; min, max: TVector; min, max: TVector; center : TVector; radius : float; ;TSurface : surface properties (4 byte) material: uint8; flag : uint8; unknown : uint8; light : uint8; ;TSphere : collision sphere (20 byte) radius : float; center : TVector; surface: TSurface; center : TVector; radius : float; surface: TSurface; ;TBox : collision box (28 byte) min, max: TVector; surface : TSurface; ;TFaceGroup : face group (see below) (28 byte) (not used) min, max: TVector; StartFace, EndFace : uint16; ;TVertex : collision mesh vertex (12 or 6 byte) float3 int163 ;TFace : collision mesh face (16 or 8 byte) a, b, c: uint32; surface: TSurface; a, b, c : uint16; material: uint8; light : uint8; * all boxes are axis-aligned Header char {4} - FourCC ("COLL", "COL2" or "COL3") uint32 {4} - file size from after this value (so 8 byte less) char {22} - collision model name short {2} - game model index (for acceleration, not a must) TBounds {40} - bounding objects, see above if (Version >= 2) { uint16 {2} - number of collision spheres uint16 {2} - number of collision boxes uint16 {2} - number of collision mesh faces uint8 {1} - number of wheels uint8 {1} - padding uint32 {4} - flags uint32 {4} - offset collision spheres uint32 {4} - offset collision boxes uint32 {4} - offset suspension lines uint32 {4} - offset collision mesh vertices uint32 {4} - offset collision mesh faces uint32 {4} - offset triangle planes (unused) if (Version >= 3) { uint32 {4} - number of shadow mesh faces uint32 {4} - offset shadow mesh vertices uint32 {4} - offset shadow mesh faces if (Version = 4) { uint32 {4} - unknown, unused } } } * All offsets in col 2/3 format are relative to after the fourcc, so file offset + 4. * Col 2/3 format does not store the number of vertices. Normally you do not need that, since you would just add the vertex index to the offset in your pointer. But if you do need it, scan the faces for the largest index. Flags: * 2 - not empty (collision model has spheres or boxes or a mesh) * 8 - has face groups (if not empty) * 16 - has shadow mesh (col 3) * apparently other flags are not used Body Version 1 Version 2/3 uint32 {4} - number of col. spheres TSphere[] {*} - col. sphere array uint32 {4} - number of unk. data (0) uint32 {4} - number of col. boxes TBox[] {*} - col. box array uint32 {4} - number of col. vertices TVertex[] {*} - col. mesh vertex array uint32 {4} - number of col. faces TFace[] {*} - col. mesh face array TSphere[] {*} - col. sphere array TBox[] {*} - col. box array TVertex[] {*} - col. mesh vertex array char {2} - optional padding FaceGroup[] {*} - col. mesh face groups uint32 {4} - number of face groups TFace[] {*} - col. mesh face array TVertex[] {*} - shad. mesh vertex array char {2} - optional padding TFace[] {*} - shad. mesh face array * The unknown section was presumably planned to hold a set of lines, used for collisions with very thin objects (like railings). But this was never confirmed, nor is it used anywhere. * The sequence of sections in the col 2/3 format as given above can be observed in every file sample. However, since there are offsets now, you could order them however you want. * There is no offset to face groups, reading them is optional. To read them, go to the start of the face array, go back 4 byte, read the amount of groups, and go back 28*GroupCount byte. But check the flag in the header for existence of face groups first. * The 2 byte padding after the vertex arrays in col 2/3 is used to provide a 4 byte alignment. It is present if the array's length leaves a rest when divided by 4, i.e. (VertexCount*6) mod 4 != 0. Annotations Data Compression and Limits In the col 2/3 format not only face indices take up half as much space (uint16 instead of uint32); also vertex coordinates are now stored as so-called fixed-point numbers. To convert such an int16 number to a floating point number, simply divide it by 128.0. But there is one major disadvantage you have to take care of: meshes are limited to dimensions of +/- 255.99 units on each axis. But this should be no problem, since objects bigger than that would defy the whole purpose of the streaming engine, and should never be used. Face Groups Faces in large col 2/3 meshes (more than 80 faces) are grouped by location, and get a bounding box. This way collision checks can be limited to a special area of interest, to speed them up significantly. Some statistics: There is an minimum average of 13.8 faces per group, maximum is 50 . On average there are 31.75 faces per group. In the grouping algorithm, a face count of > 50 is the criterion to split a group. Shadow Mesh The so-called "shadow mesh" introduced with version 3 is used to cast real-time shadows in GTA SA. Again, to save cpu time these are reduced to significant parts of the object, like bridges on map parts. Very important is that they always have to be closed! If there are holes in your mesh, you will get odd projection errors, with shadow triangles floating around. Collision Version 4 Rockstar planned a version 4 format of the collision model, but it appears to have been scrapped during development. This format introduces an additional four bytes at the end of the collision file header though its use is unknown. There are left-overs of the version 4 format loading inside of the GTA:SA engine. Through conventional methods, it is not possible to load it due to technical difficulties, but it could have been loaded on the Playstation 2 version of GTA:SA. Tools Version 1 only * CollMaker http://www.steve-m.com/downloads/tools/collmaker/ by Steve M. (2002) Very simple tool that creates single model collision files based on text cordinates as input, such as the text .x files. * CollEditor http://www.steve-m.com/downloads/tools/colleditor/ by Steve M. (2003) The first 3D editor for collision files. Allowed simple modification and management of collision models. Not very user-friendly, though, and not bug-free. * Col IO http://gtatools.com/pafiledb/pafiledb.php?action=file&id=16 by Delfi (2004) Another 3D editor. Unlike CollEditor, this one allowes to drag spheres, boxes and vertices comfortably with the mouse. Mainly suited for vehicles and quite buggy. All versions * KAMS http://www.gtaforums.com/index.php?showtopic=218318 by Kam (2005) A collection of scripts for 3D Studio Max, including one for import/export of collision files. Does not support face groups. * CollEditor II http://www.steve-m.com/downloads/tools/colleditor2/ by Steve M. (2005) And yet another 3D editor, with many features. See also Category:3D File Formats Category:GTA III Modifications Category:GTA Vice City Category:Modifications